Microsoft Dynamics CRM 4.0 is licensed on either a
per-named user or per-device model. (This is somewhat dissimilar from
some of Microsoft’s ERP offerings that have a licensing model of
concurrency.) Therefore, each and every user who accesses Microsoft
Dynamics CRM 4.0 must be identified and set up in Microsoft Dynamics CRM
as a valid user with a valid role. End-user licensing is referred to as
client access licenses (CALs). Figure 1 shows how users are administered in Microsoft Dynamics CRM 4.0.
Figure 2
shows the device model that is commonly used in call center and
manufacturing organizations, where multiple users may use the same
computer (but not at the same time).
In Figure 2,
it is important to remember that all three users listed will need to be
added to Microsoft Dynamics CRM as valid users (as shown in Figure 3.1). However, instead of purchasing three separate CALs, one for each user, only one CAL must be purchased.
Note
Be careful when
considering your licensing requirements and evaluating the device CAL.
If at any point any of the users access another computer that has not
been identified as the device computer, the organization may be out of
compliance.
Contrast Figure 2 with Figure 3, which shows three figures, and therefore requires three CALs.
Note
Microsoft Dynamics CRM
4.0 is not offered with fewer than five user CALs (either device or
named user). The examples provided thus far are for illustrative
purposes.
The end result from both of these examples is the following:
From a licensing perspective, you will have either one CAL (a device CAL) or three named-user CALs.
From
a CRM administration perspective, you will have three users set up and
configured with valid roles in Microsoft Dynamics CRM.
This example is included to
show the extension of Microsoft Dynamics CRM when a valid user is
required (which is often the case when building components that
integrate with Microsoft Dynamics CRM).
A frequent
mistake that amateur integrators make is to just take advantage of an
existing user CAL and use that CAL as the hard-coded
authentication/integration credentials. Although this is not necessarily
a problem (and several of our examples include such a method), it is
important to realize that Microsoft recognizes such usage as a method of
access, and it may therefore place the organization in
license-compliance risk. This is especially true if the system is
designed to perform any level of integration with any application that
delivers data outside of the domain.
In addition, it is
important to remember that Microsoft Dynamics CRM CALs are instance
based, and with multiple on-premise servers (such as with a server
farm), only the single-user CAL is required, regardless of the number of
actual CRM servers.
As stated previously,
Microsoft has positioned Microsoft Dynamics CRM as a platform and has
therefore developed a licensing model for it that enables access to it
without requiring a license for every user. But, a license is required
if data is going to be accessed across the organizational domain; this
method of access is referred to as using the connector model or
connector licensing.
External Connector License
The Microsoft
External Connector license allows organizations to extend Microsoft
Dynamics CRM data both across disparate applications and across the
domain.
Note
Although
the External Connector license is purchased separately, there is no
configuration made to Microsoft Dynamics CRM that reflects the existence
of this license.
The External Connector license is available in two different formats for Microsoft Dynamics CRM:
The intention of the
Limited External Connector is to allow interaction on a read-only level
with the Microsoft Dynamics CRM data, whereas the Full External
Connector allows full read/write on the Microsoft Dynamics CRM data.
(The cost of the license reflects the restriction levels; the Limited
External Connector is approximately one-third the cost of the Full
External Connector.)
Connection Options
Finally, it is
appropriate to mention that the method of access is completely optional
to the end user. There are three ways to interact with Microsoft
Dynamics CRM data:
Note
Although all three options are included, it is recommended to use only the first two options listed here.
Any direct interaction directly with the SQL Server CRM tables is highly
cautioned against and may place the modified records (if not the entire
system) into an unstable state, and should be performed only by an
experienced CRM partner.
Microsoft Dynamics
CRM web services allow applications to consume CRM business rules and
data directly from the CRM web server. In some cases, this is the
preferred method, and creating a connection directly to the SQL Server
database is impractical.
SQL Server CRM filtered views (see Figure 4)
are similar to CRM web services in that they’re designed to be used by
end users who are performing integrations, because they enforce security
roles, which are important when considering integration applications
that can be used by a variety of users in an organization. In addition,
the views can be used for read-only access, but should not be used for
write access.
Note
It
is important to remember that Microsoft Dynamics CRM can have user
roles that are disproportionate from their Active Directory roles, and
therefore a low-level CRM user may be a system administrator in Active
Directory (and vice versa).
Although our
discussion references all the methods listed previously, be sure to
understand the implications of using one versus the other.
